-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add grpc unary server interceptor #312
base: master
Are you sure you want to change the base?
Conversation
This project is based heavily on the [grpc-go-middleware libraries][1] and a [pull-request][2] from the [sentry-go library][3]. [1]: https://github.com/grpc-ecosystem/go-grpc-middleware [2]: getsentry/sentry-go#312 [3]: getsentry/sentry-go#240
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shouichi thanks for the PR. Sorry, I didn't have the bandwidth to review it over the holiday season.
The current draft looks promising, would love to see some test cases and examples how it will be used.
@rhcarvalho Added tests. Please take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good!
A couple of questions / suggestions. I think we can merge this soon, thank you!
Also adresse other minor/style issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rhcarvalho Changed to use the functional options pattern. Please take a look.
} | ||
|
||
// Option configures reporting behavior. | ||
type Option func(*options) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should separate options for server/client and unary/stream. Probably they won't diverge too much?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, perhaps what would give us more flexibility is
type Option func(*options) | |
type Option interface{ | |
apply(*options) | |
} |
Later down the road it could become
type Option interface{
applyServer(*serverOptions)
applyClient(*clientOptions)
// ...
}
It would allow us to share options between servers and clients, unary and stream.
Though I'm not sure that's actually a good idea. One downside is discoverability and documentation. If server/client/etc options have the same type, all of them will be grouped together in godoc. If an option doesn't make sense to a certain type (client/server/unary/stream), that would also require documentation to explain instead of being impossible to compile because of incompatible types.
I think the options we have right now are "interceptor options", and should probably be the same for other types of interceptors? Are there other existing concepts we'd expand into?
type Option func(*options) | |
type InterceptorOption interface{ | |
apply(*options) | |
} |
If there is only reason to be one type of option, for interceptors, then we can keep the name simple, Option
.
Sorry, busy day, didn't have much time to think this through but wanted to share and continue the conversation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure but both of the following changes shouldn't break user code because they don't directly use Option
. So can we start simple?
- Changing
type Option func(*options)
totype Option interface {}
. - Renaming
Option
toInterceptorOption
.
Sorry, busy day, didn't have much time to think this through but wanted to share and continue the conversation.
No worries! We don't need to rush. I (we?) just want to agree on a good design ;)
Co-authored-by: Aubrey Dean <[email protected]>
@rhcarvalho @spaceweasel Hi, it's been a while but could you take another look at this PR? |
I was looking for this. Glad to see it's only a review away from getting it merged! |
Hi, it's been some time since this has been open. Are there plans to merge this in? |
This is exactly what I'm looking for. The pull request has been open for a while. Any chance this still can get a review? @rhcarvalho @spaceweasel |
Any news? |
Really looking forward to this getting merged! |
Can't wait to see it's merged. This is exactly what I was looking for! Thanks a lot |
Any updates. If it needs any help, i can do it. |
Still relevant, please update status |
Could this maybe be turned into a separate package if it's not going to be merged? |
there's a seperate package here but code is not exactly same. https://github.com/johnbellone/grpc-middleware-sentry using this package until this PR merged can be a temporal solution. |
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
This is a draft PR to support grpc (see #240). The main goal is to gather feedback and agree on the interface. Thus tests are not written yet. Any feedback/comments are welcomed. Thanks!